-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rust: Avoid location-based variable analysis #18462
Conversation
9da26a8
to
6c0cfb0
Compare
6c0cfb0
to
4c83022
Compare
4c83022
to
33e6d63
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 6 out of 10 changed files in this pull request and generated 1 comment.
Files not reviewed (4)
- rust/ql/lib/codeql/rust/elements/internal/VariableImpl.qll: Language not supported
- rust/ql/test/library-tests/dataflow/strings/inline-taint-flow.expected: Language not supported
- rust/ql/test/library-tests/variables/variables.ql: Language not supported
- rust/ql/test/query-tests/unusedentities/UnusedValue.expected: Language not supported
Tip: If you use Visual Studio Code, you can request a review from Copilot before you push from the "Source Control" tab. Learn more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks really great :)
sink(format!("{}", s1)); // $ MISSING: hasTaintFlow=34 | ||
sink(format!("{s1} and {s3}")); // $ MISSING: hasTaintFlow=34 | ||
sink(format!("{}", s1)); // $ hasTaintFlow=34 | ||
sink(format!("{s1} and {s3}")); // $ hasTaintFlow=34 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hurrah! 🎉
Before this PR, we were relying on the source location of variable declarations and accesses for name-binding. However, this does not work for variables declared/accessed inside macros, where the original source locations are not available.
This PR consequently rewrites the logic to be purely AST based, by computing pre-order tree-traversal numbers for (relevant) AST nodes, and then using those numbers instead of source location start-line/columns.
This approach mostly works, except we are not able to respect the macro hygiene rules of Rust, since the extractor does not supply us with a syntax context. I originally noticed this in an earlier DCA run, where a new
rust/unused-variable
false-positive result was added, and I have consequently added this FP to our test suite.Commit-by-commit review is suggested.